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Coordination languages simplify design and development of concurrent systems. Particularly, exoge¬ 
nous coordination languages, like BIP and Reo, enable system designers to express the interactions 
among components in a system explicitly. In this paper we establish a formal relation between BI(P) 
(i.e., BIP without the priority layer) and Reo, by defining transformations between their semantic 
models. We show that these transformations preserve all properties expressible in a common se¬ 
mantics. This formal relation comprises the basis for a solid comparison and consolidation of the 
fundamental coordination concepts behind these two languages. Moreover, this basis offers transla¬ 
tions that enable users of either language to benefit from the toolchains of the other. 


1 Introduction 

Context, Over the past decades, architecture description languages (ADL) and coordination languages 
have emerged as fundamental tools for tackling complexity in the design of correct-by-construction com- 
ponentised software systems [15], However, no language has yet emerged as a de facto standard, and 
no consensus exists on how to properly design such languages, either. BIP [9, 10] and Reo [3] each 
addresses this complexity and provides a formal semantic framework, which allows reasoning about and 
proving correctness of coordination as a first-class entity. 

BIP is a language for the construction of concurrent systems by superposing three layers: behaviour, 
interaction and priorities. The layered approach of BIP separates concerns between interaction and com¬ 
putation. This is essential for component-based design of concurrent systems, because it allows global 
analysis of the coordination layer and reusability of written code. 

Reo is a language for compositional specification of coordination protocols, i.e., protocols modeling 
the synchronization and dataflow among multiple components. These protocols consist of graph-like 
structures, called connectors. Reo connectors may compose together to form more complex connectors, 
allowing reusability and compositional construction of coordination protocols. 

We provide a more detailed introduction to BIP and Reo in Section 2. 

Motivation. Both BIP and Reo advocate the necessity of separ ating coordination mechanisms from the 
coordinated components. In BIP one refers to this separation as the architecture-based design approach 
[11], Reo literature uses the term exogenous coordination to describe the same fundamental principle 
[3,4,20]. Despite this fundamental agreement, the design choices underlying BIP and Reo differ. For 
example, BIP uses stateless interactions, while Reo allows stateful connectors. Establishing a formal 
relation between BIP and Reo is necessary to discover fundamental principles that drive the design of 
coordination languages. 

Translations exist between numerous other coordination models and BIP and Reo, individually [12, 
13,21,22], Hence, a formal relationship between BIP and Reo yields insight, albeit indirect, into the 
relation of each with a wider range of related work. 
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Furthermore, establishing a formal relationship between BIP and Reo enables encodings that allow 
each of the two frameworks to benefit from tools and theoretical results obtained for the other. These 
toolchains include tools for editing, code generation, and model checking. We refer to [1] and [2,4] for 
details. 

Contributions. We relate the most important semantic models of BI(P) 1 (i.e., BIP without the pri¬ 
ority layer) and Reo. For Reo we consider port automata and constraint automata, which model Reo 
connectors at different levels of abstraction [16]. For BI(P) we consider BIP architectures [6] and BIP 
interaction models, i.e., sets of simple interaction expressions [11]. 

First, we provide a short summary of BIP and Reo in Section 2. Then, in Section 3, we define 
mappings between port automata and BIP architectures, and show that these distribute over composition 
modulo semantic equivalence. Hence, it is possible to compute these translations incrementally, in order 
to speed them up. In Section 4, we define mappings between stateless constraint automata and BIP 
interaction models. We show that all transformations preserve all properties of observable dataflow, 
which, for example, enables one to transfer safety properties established for some generated code, or the 
results of model checking from one model to the other. These mappings in the data-sensitive domain do 
not distribute over composition, but in Section 5 we briefly discuss a different translation scheme that 
still allows incremental translation. There, we discuss also the differences and similarities between BI(P) 
and Reo and other coordination languages, and point out future work. 

Related Work. Other authors have related and compared both BIP and Reo to other coordination 
languages. Bruni et al. encode BIP models into Petri nets [12], and Chkouri et al. present a translation 
of AADL into BIP [13]. Procnca and Clarke provide a detailed comparison between Ore and Reo [21]. 
Arbab et al. provide a translation of Reo connectors into the Tile Model [5]. Krause compared Reo to 
Petri nets [18]. Talcott, Sirjani and Ren connect both ARC and PBRD to Reo by providing mappings 
between their semantic models [22], 

Although an indirect comparison of BIP and Reo through their respective comparisons with other 
models, e.g., Petri nets, is certainly possible, the direct and formal translations we present in this paper 
allows direct translation tools between BIP and Reo, that are otherwise difficult, if not impossible, to 
construct based on such indirect comparisons. 

2 Overview of BIP and Reo 

2.1 BIP 

A BIP system consist of a superposition of three layers: Behaviour, Interaction, and Priority. The be¬ 
haviour layer encapsulates all computation, consisting of atomic components processing sequential code. 
Ports form the interface of a component through which it interacts with other components. BIP repre¬ 
sents these atomic components as Labeled Transition Systems (LTS) having transitions labeled with ports 
and extended with data stored in local variables. The second layer defines component coordination by 
means of BIP interaction models [11]. For each interaction among components in a BIP system, the 
interaction model of that system specifies the set of ports synchronized by that interaction and the way 

'Although BIP's notion of priority is equally applicable to the constraint automata semantics of Reo, Reo provides no syntax 
to specify such global priority preferences. Reo does have a weaker priority mechanism to specify local preferences by means 
of context sensitive channel LossySync, that prefers locally maximal dataflow. 
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Figure 1: BIP components (a); coordinator (b). 


data is retrieved, filtered and updated in each of the participating components. In the third layer, priorities 
impose scheduling constraints to resolve conflicts in case alternative interactions arc possible. In the rest 
of this paper, we disregard priorities and focus mainly on interaction models (cf., footnote 1). 

Data-agnostic semantics. We first introduce a data-agnostic semantics for BIP. 

Definition 1 (BIP component [6]). A BIP component C over a set of ports Pc is a labeled transition 
system (Q,q°,Pc,—t) over the alphabet 2 Pc . If ^ is a set of components, we say that 2? is disconnected 
iff Pc H P ( t = 0 for all distinct C. C' € c to. Furthermore, we define Pc = (J 

Then, BIP defines an interaction model over a set of ports P to be a set of subsets of P. Interaction 
models arc used to define synchronisations among components, which can be intuitively described as 
follows. Given a disconnected set of BIP components ^ and an interaction model y over Pc, the state 
space of the corresponding composite component yi'SP) is the cross product of the state spaces of the 
components in y('S') can make a transition labelled by an interaction N € y iff all the involved com¬ 
ponents (those that have ports in N ) can make the corresponding transitions. A straightforward formal 
presentation can be found in [10] (cf., Definition 3 below). Thus, BIP interaction models arc stateless: 
every interaction in y is always allowed; it is enabled if all ports in the interaction arc ready. However, [6] 
shows the need for statefull interaction, which motivates BIP architectures 

Definition 2 (BIP architecture [6]). A BIP architecture is a tuple A = (2f, P,\ , y), where r SP is a finite 
disconnected set of coordinating BIP components. Pa is a set of ports, such that P-c = Ucetf A; Q Pa, and 
yC 2 Pa is a data-agnostic interaction model. We call ports in P\ \A? dangling ports of A. 

Essentially, a BIP architecture is a structured way of combining an interaction model y with a set 
of distinguished components, whose only puipose is to control which interactions in y are applicable at 
which point in time (which depends on the states of the coordinating components). 

Definition 3 (BIP architecture application [6]). Let A = ( 2 ?. Pa . y) be a BIP architecture, and PS a set 
of components, such that PSP'S? is finite and disconnected, and that Pa C PggPP^. Write PS IJ W — 
{Bj | i 6 /}, with Bj = (Qi,cp Then, the application A(PS) of A to PS is the BIP component 

where ->• is the smallest relation satisfying: (qfici A (q')ici whenever 

1. N = 0, and there exists an i G / such that q t A; q\ and ql = qj for all j e AO'}; or 

2. /Vf] Pa G y. and for all i G I we have N n P, f 0 implies cp ' V A q], and NHP; = 0 implies q\ = cp. 

The application A (PS), of a BIP architecture A to a set of BIP components PS, enforces coordination 
constraints specified by that architecture on those components [6]. The interface Pa of A contains ah ports 
Af of the coordinating components ,: SP and some additional ports, which must belong to the components 
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in £$. In the application A(S8), the ports belonging to P,\ can participate only in interactions defined by 
the interaction model y of A. Ports that do not belong to Pa are not restricted and can participate in any 
interaction. 

Intuitively, an architecture can also be viewed as an incomplete system: the application of an archi¬ 
tecture consists in “attaching” its dangling ports to the operand components. The operational semantics 
is that of composing all components (operands and coordinators) with the interaction model as described 
in the previous paragraph. The intuition behind transitions labelled by 0 is that they represent obsen’cible 
idling (as opposed to internal transitions). This allows us to “desynchronise” combined architectures (see 
Definition 4) in a simple manner, since coordinators of one architecture can idle, while those of another 
performs a transition. Note that, if N = 0, in item 2 of Definition 3, N n P, = 0, hence also, t( l = q\, for 
all i. Thus, intuitively, one can say that none of the components moves. Item 1, however, does allow one 
component to make a real move labelled by 0, if such a move exists. Thus, the transitions labelled by 0 
interleave, reflecting the idea that in BIP synchronisation can happen only through ports. 

Example 1 (Mutual exclusion [6]). Consider the components B\ and Bj in Figure 1 (a). In order to ensure 
mutual exclusion of their work states, we apply the BIP architecture A 12 = ({Ci 2 },Pi 2 , 712)5 where C 12 is 
shown in Figure 1(b), Pn = {biMMiJtJiJn} and y n = {0, {h,bi 2 }, {b 2 ,bi 2 }, {/ 1 J 12 }, {/2,/i2>}. 
The interface Pi 2 of A 12 covers all ports of B\, lh_ and C 12 . Hence, the only possible interactions arc those 
that explicitly belong to 712 - Assuming that the initial states of B\ and B 2 arc sleep, and that of C 12 is 
free, neither of the two states (free,work,work) and (taken, work, work) is reachable, i.e. the mu¬ 
tual exclusion property (q\ f work) V (q 2 7 = work)—where q\ and q 2 are state variables of B\ and B 2 
respectively—holds mA\ 2 {B\,B 2 ). A 

Definition 4 (Composition of BIP architectures [6]). Let Ai = ( r: d\. P\. 7 ) and A 2 = (A). P 2 . 72 ) be two 
BIP architectures. Recall that P^. = Ucek, Pc* f° r f = 1,2. If P^ n Pg 2 = 0, then Ai ©A 2 is given by 
(f£\ U ^ 2 ,-Pi U P 2 , 712)5 where 712 = {N C Pi UP 2 \ NflPj G 7 , for i = 1,2}. In other words, 712 is the 
interaction model defined by the conjunction of the characteristic predicates of 71 and 72 . 

Data -aware semantics. Recently, the data-agnostic formalization of BIP interaction models was ex¬ 
tended with data transfer, using the notion of interaction expressions [11]. Let £? be a global set of ports. 
For each port p £ let x p : D p be a typed variable used for the data exchange at that port. For a set 
of ports P C let X P = (x p ) peP . An interaction expression models the effect of an interaction among 
ports in terms of the data exchanged through their corresponding variables. 

Definition 5 (Interaction expression [11]). An interaction expression is an expression of the form 
(p <- Q).[g(X Q ,X L ) : (Xp,X L ) := up(X Q ,X L ) // (X Q ,X L ) := dn(X P ,X L )\, 

where P,Q C arc top and bottom sets of ports; L C g? is a set of local variables; g(XQ,X£) is 
the boolean guard ; up(Xq,Xl) and dn{X P .Xp) arc respectively the up- and downward data transfer 
expressions. 

For an interaction expression a as above, we define by top(a) = P, bot(a) = Q and supp(a) — P U Q 
the sets of top, bottom and all ports in a , respectively. We denote g a , up a and dn a the guard, upward 
and downward transfer corresponding expressions in a. 

The first paid of an interaction expression, (P Q), describes the control flow as a dependency 
relation between the bottom and the top ports. The expression in the brackets describes the data flow, 
first “upward”—from bottom to top ports—and then “downward”. The guard g(X(j.X[j relates these two 
parts: interaction is enabled only when the values of the local variables together with those of variables 
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associated to the bottom ports satisfy a boolean condition. As a side effect, an interaction expression 
may also modify local variables in X b . Intuitively, such an interaction expression can fire only if its guard 
is true. When it fires, its upstream transfer is computed first using the values offered by its participating 
BIP components. Then, the downstream transfer modifies all the port variables with updated values. 

Definition 6 (BIP interaction models [11]). A (data-aware) BIP interaction model is a set 1 of simple 
BIP connectors a, which are BIP interaction expressions of the form 

(M A).[g(Z A ) : (x w ,X L ) : = up(X A )//X A := dn(x w ,X L )], 

where w £ P is a single top port, A C P is a set of ports, such that w A , and neither up nor g involves 
local variables. 

Example 2 (Maximum). Let = {a.b. w,l\ be a set of ports of type integer, i.e., x p : D p = Z, for all 
p € A’, and consider the interaction expression (simple BIP connector) 

a m ax = ({w} {a,£}).[tt: x/ :=max(x a ,x b ) //x a ,x b :=x/], 

where tt is true. First, the connector takes the values presented at ports a and b. Then, the simple BIP 
connector a max computes atomically the maximum of x„ and x b and assigns it to its local variable x/. 
Finally, a max assigns atomically the value of x/ to both x a and x b . A 

BIP interaction expressions capture complete information about all aspects of component interaction— 
i.e. synchronisation and data transfer possibilities—in a structured and concise manner. Thus, by exam¬ 
ining interaction expressions, one can easily understand, on the one hand, the interaction model used to 
compose components and, on the other hand, how the valuations of data variables affect the enabledness 
of the interactions and how these valuations are modified. Furthermore, a formal definition of a compo¬ 
sition operator on interaction expressions is provided in [11], which allows combining such expressions 
hierarchically to manage the complexity of systems under design. Since any BIP system can be flattened, 
this hierarchical composition of interaction expressions is not relevant for the semantic comparison of 
BIP and Reo in this paper. Nevertheless, the possibility of concisely capturing all aspects of component 
interaction in one place is rather convenient. 

2.2 Reo 

Reo is a coordination language wherein graph like structures express concurrency constraints (e.g., syn¬ 
chronization, exclusion, ordering, etc.) among multiple components. These structures consist of a com¬ 
position of channels and nodes, collectively called connectors or circuits. A channel in Reo has exactly 
two ends, and each end either accepts data items, if it is a source end, or offers data items, if it is a sink 
end. Moreover, a channel has a type for its behaviour in terms of a formal constraint on the dataflow 
through its two ends. Its abstract definition of channels and its notion of channel types make Reo an 
extensible programming language. Beside the established channel types (Table 1 contains some of them) 
Reo allows arbitrary user-defined channel types. 

Multiple ends may glue together into nodes with a fixed merge-replicate behaviour: a data item out 
of a single sink end coincident on a node, atomically propagates to all source ends coincident on that 
node. This propagation happens only if all their respective channels allow the data exchange. A node is 
called a source node if it consists of source ends, a sink node if it consists of sink ends, and a mixed node 
otherwise. Together, the source and sink nodes of a connector constitute its set of boundary nodes/ports. 
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Figure 2: Fool-proof (c) mutual exclusion protocol in Reo, composed from a BIP-like (a) mutual exclu¬ 
sion connector and an altenator connector (b), and the generated Reo circuit (d) from Example 5. 


Example 3. Figure 2(a) shows a Reo connector that achieves mutual exclusion of components B\ and 

exactly as the BIP system shown in Figure 1 does. This connector consists of a composition of 
channels and nodes in Table 1. The Reo connector atomically accepts data from either b\ or hj and puts 
it into the FIF01 channel, a buffer of size one. A full FIF01 channel means that B\ or Bi holds the 
lock. If one of the components writes to f\ or ( 2 , the SyncDrain channel flushes the buffer, and the lock 
is released, returning the connector to its initial configuration, where B\ and Bi can again compete for 
exclusive access by attempting to write to b\ or Z? 2 . 

Note that this connector is not fool-proof. Even if B\ takes the lock. Bo may release it, and vice 
versa. Hence, exactly as the BIP architecture in Figure 1, the Reo connector in Figure 2(a) relies on the 
conformance of the coordinated components B \ and /F. The expected behaviour of /?,, i = 1,2, is that 
it alternates writes on the bj and f), and that every write on f comes after a write on bj. Depending on 
such assumptions may not be ideal. The connector, shown in Figure 2(b), makes this expected behaviour 
explicit. By composing two such connectors with the connector in Figure 2(a), we obtain a fool-proof 
mutual exclusion protocol, as shown in Figure 2(c). Figure 4(c) shows the constraint automaton seman¬ 
tics of the connector in Figure 2(c). Unlike the case of the connector in Figure 2(a) or the BIP architecture 
in Figure 1, non-compliant writes to bi or ft ports of the connector in Figure 2(c) will block component 
Bj, but cannot break the mutual exclusion protocol that this connector implements. A 

Formal semantics of Reo. Reo has a variety of formal semantics [4, 16]. In this paper we use its 
operational constraint automaton (CA) semantics [8]. 

Definition 7 (Constraint automata [8]). Fet JV be a set of nodes and A a set of data items. A data 
constraint is a formula in the language of the grammar 

g T | -.g | g Ag | 3d p (g) | d p = v, with p € JP ,v£f, 

where variable d p represents the data assigned to (i.e., exchanged through) port p. Fet |= denote the 
obvious satisfaction relation between data constraints and data assignments 8 : N — > with N C jV , 
and write DC(<A',@) for the set of all data constraints. A constraint automaton (over data domain A) 
is a tuple srf = F</o) where Q is a set of states, jV is a finite set of nodes, fC0x2‘ / x 

DC(^F, $>) x Q is a transition relation, and qo £ Q is the initial state. 

In this paper, we consider only finite data domains, although most of our results generalize to infinite 
data domains. Over a finite data domain, the data constraint language DC(<sP, 3>) is expressive enough 
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Sync LossySync SyncDrain FIF01 Node 



Table 1: Some primitives in the Reo language with CA semantics over a singleton data domain A. 


to define any data assignment. For notational convenience, we relax, in this paper, the definition of data 
constraints and allow the use of set-membership and functions in the data constraints. However, we 
preserve the intention that a data constraint describes a set of data assignments. 

Table 1 shows the CA semantics for some typical Reo primitives. The CA semantics of every Reo 
connector can be derived as a composition of the constraint automata of its primitives, using the CA 
product operation in Definition 8 . On the other hand, every constraint automaton (over a finite data 
domain) translates back into a Reo connector [7], Because of this correspondence, we may consider Reo 
and CA as equivalent, and focus on constraint automata only. 

If a constraint automaton stf has only one state, .c/ is called stateless. If the data domain A of s/ 
is a singleton, s/ is called a port automaton [17]. In that case, we omit data constraints, because all 
satisfiable constraints reduce to T. 

Definition 8 (Product of CA [ 8 ]). Let s/i = {Qi,sYi, — >i,qo,i) be a constraint automaton, for / = 1,2. 
Then the product sF\ x s /2 of these automata is the automaton (Q\ x (A, JV\ U ^ 2 , —(< 70,1 • < 7 o. 2 ))- whose 

transition relation is the smallest relation obtained by the rule: (^ 1 ,^ 2 ) N . iUN2 : 8lAg - 2 > whenever 

1. c/i — 1 ’ - V 1 q \, q 2 N - 2 ' S - 2 > 2 q' 2 , and N\ Cl 0 T 2 = N 2 Cl jV\, or 

2. qi 4v N j = Sj = T, q'j = qj , and Nj Cl JFj = 0 with j € {1,2} \ {/}. 

It is not hard to see that constraint automata product operator is associative and commutative modulo 
equivalence of state names and data constraints. 

Definition 9 (Hiding in CA [ 8 ]). Let sF = be a constraint automaton, andP = {pi,... ,p„} 

a set of nodes. Then hiding nodes P of sF yields an automaton 3P(&?) = (Q. ./L \ P. where —^3 

is given by {(q,N\P,3d pi ■3d Pn {g),q') \ (, q,N,g,q') € ->}. 

The hiding operator affects only transition labels, and preserves the structure of the automaton. Hence 
the hiding operator offers a technique to alter the interface of a component or connector without mod¬ 
ifying its behaviour. As hiding of non-shared nodes distributes over the product, hiding of non-shared 
nodes commutes with constraint automata product. 

Example 4 (Product and hide). Consider the Reo connectors in Figure 2. Using Definition 8 , and the 
primitive constraint automata from Table 1, we find their CA semantics as shown in Figures 4(a), 4(b), 
and 4(c), respectively. If we compute the product of the automaton si 0 in Figure 4(a) with the automata 
s/i, i = 1,2, in Figure 4(b), then we obtain an automaton s/, whose paid reachable from the initial state 
(0,0,0) is shown in Figure 4(c). A 
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(a) data-agnostic domain (b) data-sensitive domain 


Figure 3: Translations and interpretations in data-agnostic and data-sensitive domain. 

3 Port automata and BIP architectures 

To study the relation between BIP and Reo with respect to synchronization, we start by defining a cor¬ 
respondence between them in the data-agnostic domain. This correspondence consists of a pair of map¬ 
pings between the sets containing semantic models of BIP and Reo connectors. For the data independent 
semantic model of Reo connectors we choose port automata: a restriction of constraint automata over 
a singleton set as data domain. We model BIP connectors by BIP architectures introduced in [6]. In 
order to compare the behaviour of BIP and Reo connectors we interpret them as labeled transition sys¬ 
tems. We define a mapping reoj that transforms BIP architectures into port automata, and a mapping 
bip! that transforms port automata into BIP architectures. We then show that these mappings preserve 
(1) properties closed under bisimulation, and (2) composition structure modulo semantic equivalence. 

3.1 Interpretation of BIP and Reo 

To compare the behaviour of BIP and Reo connectors, we interpret all connectors as labeled transitions 
systems with one initial state and an alphabet 2 P , for a set of ports P. We write LTS for the class of all 
such labeled transition systems. 

Figure 3(a) shows our translations and interpretations. The objects PA, Arch and LTS are, respec¬ 
tively, the classes of port automata, BIP architectures, and labeled transition systems. The mappings 
bipj, reo], f | and g,, respectively, translate Reo to BIP, BIP to Reo, Reo to LTS, and BIP to LTS. 

We first consider the semantics of connectors. Since BIP connectors differ internally from Reo 
connectors, we restrict our interpretation to their observable behaviour. This means that we hide the 
ports of the coordinating components in BIP architectures. For port automata this means that for our 
comparison, we implicitly assume that all names represent boundary nodes. 

The interpretation of a port automaton in LTS is defined by 

fi((Q,<sK ,-Lc/o)) = (2)2" y >,qo)- (1) 

Hence f i acts essentially as an identity function, justifying our choice of interpretation. Next, we define 
the interpretation of BIP architectures using their operational semantics obtained by applying them on 
dummy components and hiding all internal ports. Let A = (W P. y) be a BIP architecture with coordi¬ 
nating components ^ = {Ci,...,C„}, n > 0, and C, = {Qj,qf l). Recall that P# = \JjPi is the set 
of internal ports in A. Define D = ( {qn } ,q d.P.{( qi,.N.q d ) | 0 / N C P \ Py; }) as a dummy compo¬ 
nent relative to the BIP architecture A. Using Definition 3, we compute the BIP architecture application 
A({D}) = (OILi Qi) x { c 1d},(.(1 0 A1d),P, —> s ) °f A to its dummy component D. Then, 

gi (A) = (U'UQi X {dD},2 p \ p ^ ,{((q,q D ),N\P^,(q’ ,q D )) | (q ,q D ) (q',9z>)}, (qV/o)) (2) 
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(a) BIP-like mutex (b) (c) Fool-proof mutex (d) (e) reoi(Ai 2 ) 


Figure 4: CA representations (a), ( b ), and (c) of Reo connectors Figures 2(a), 2(b), and 2(c), respec¬ 
tively; translation of the interaction model ( d) and BIP architecture (e) of Figure 1. 


In other words, g] (A) equals A({D}) after hiding all internal ports P<g. Note that we based our interpreta¬ 
tion g] on the operational semantics of BIP architectures, i.e., BIP architecture application. This justifies 
the definition of interpretation of architectures. 

Because of hiding, g| is not injective. Hence, our interpretation of BIP architectures induces a non¬ 
trivial equivalence given by equality of interpretations. In the sequel, we use a slightly stronger version 
of equivalence based on bisimulation [19]. 

Definition 10 (Bisimulation [19]). If L,- = (Qj,2 Pi , — >i,q { -) G LTS, i = 1,2, then L\ and Li arc bisimilar 
(Li = Li) iff P\ = Pi and there exists R C Q 1 x Q 2 such that (q { \.q { \) G R, and (q\ .qi) G R implies, for all 

N E 2 P ‘, i,j G{1,2} with i / j, if qi q' r then, for some q' r qj -Vj q'j and (q\ ,q' 2 ) G R- 

Definition 11 (Semantic equivalence). Let .c/eF? G PA be port automata and A, B G Arch be BIP archi¬ 
tectures. Then, .c/ and S3 arc semantically equivalent (.c/ ~ izl) iff f 1 (.f/) = fi(^), and A and B arc 
semantically equivalent (A B) iff gl (A) = gl (B). 

With a common semantics for BIP and Reo, we can define the notion of preservation of properties 
expressible in this common semantics. Recall that a property of labeled transition systems corresponds 
to the subset of labeled transition systems satisfying that property. 

Definition 12. Let P C LTS be a property. Then, hip, preserves P iff fi (.c/) GP A gl (bip 1 {rz/)) G P for 
ah , 5 / G PA. Similarly, reoi preserves P iff gl (A) G P f 1 (reoi (A)) G P for all A G Arch. 

3.2 BIP to Reo 

To translate BIP connectors to Reo connectors, we first determine what elements of BIP architectures 
correspond to Reo connectors. Our interpretations of port automata and BIP architectures show that 
dangling ports in BIP architectures correspond to boundary port names in port automata. Furthermore, 
the mutual exclusion of the interactions in an interaction model in a BIP architecture simulates mutually 
exclusive firing of transitions in port automata. The definition of a coordinating component in a BIP 
architecture is almost identical to that of a port automaton, yielding an obvious translation. 

Let A = FA, P. y) be a BIP architecture, with 'A = {C 1 ,...,C„}. Each C, corresponds trivially to a 
port automaton C,. Let .e/y = ({q\.P.^.q) be the stateless port automaton over P with transition relation 
-> defined by { (q.N,q) N G y}. Then s//y can be seen as the port automata encoding of the interaction 
model y. Recall that PV = Urgv; ^c- The corresponding port automaton of A is given by 

reoi(A) = 3PV(Ci x • • C n x (3) 
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Example 5. We translate the BIP architecture in Example 1 using (3). First, we transform 712 into a 
port automaton ,c/y p , shown in Figure 4(d). Then, we compute the product of .e/y l2 with the coordinating 
component C 12 to obtain the port automaton corresponding to the BIP architecture A 12 , shown in Fig¬ 
ure 4(e). As mentioned in section Section 2.2, we can transform the port automaton in Figure 4(e) into a 
Reo connector, using the method described in [7], This mechanical translation yields the Reo connector 
in Figure 2(d). Here, the dot in the FIF01 buffer indicates that its initial state is the full state. The 
crossed node represents an exclusive router, which atomically takes data from a coincident sink end, and 
provides it to a single coincident source end. Note that the port automaton semantics of the connector in 
Figure 2(a) (see Figure 4(a)) is similar to the automaton in Figure 4(e), up to empty transitions. A 

3.3 Reo to BIP 

In BIP, interaction is memoryless. This means that a stateful channel in Reo must translate to a coordi¬ 
nating component. In fact, we may encode the whole Reo connector as one such component. 

Fet s^i, i = 1,2, be two port automata, and let p £ .,4) n jYi be a shared port of and ,sA. Suppose 
that we know how to translate into a BIP architecture A,-. If p is not a dangling port of Ai, then, 
by symmetry, p is not a dangling port of A 2 . But now, Ai and A 2 arc not composable, because there 
components arc not disconnected. Hence, since we want the translation to preserve composition, p 
should be a dangling port. 

Fet sY = (Q.-/V,^,qo) be a port automaton. We construct a corresponding BIP architecture. Du¬ 
plicate all ports in jV by defining N' = {n! \ n £ N} for all N C jY . We do not use a port n', for n £ jV , 
for composition. Their exact name is therefore not important, but merely their relation to its dangling 
brother n. Trivially, sY = (Q,qo,^' r c ), with -* c = {{q,N' ,q') | ( q,N,q ') £ ->}, is a BIP component 
(cf., Definition 1). Essentially, .c/ and . 0 / arc the same labeled transition system. Now we define: 

bi Pl (=0 = ,{NCN' | ]VC/}). (4) 

Thus, bi p | uses the port automaton as the coordinating component of the generated BIP architecture. 

Example 6. Fet ,c/ be the port automaton in Figure 4(b) over the name set jY = {/?;,/)}. We determine 
bip^g/). Obtain sY by adding adding a prime to each port in ,c/. The interaction model of bip| (.?/) 
consist of {NUN' \ N C V } = {0, {bi, (?'•}, {fi,f- },{&;, b\,fp //}}. Hence, is given by th BIP 

architecture //}})- 

3.4 Preservation of properties 

To confirm that translations reoi and bipj preserve properties, we first investigate whether Figure 3(a) 
commutes, i.e., fi(reoi(A)) = g, (A) and g x (bipj (j 2 ^)) = for A £ Arch and sY £ PA. 

First, note that the equations fi(reoi(A)) = g, (A) and g x (bipj (ja/)) = fi(^/) cannot hold, because 
their state spaces differ. For example, g[ alters the state space by adding the state of a dummy component, 
and reoj adds the state of the port automaton encoding of the interaction model. Therefore we view these 
equations modulo bisimulation of labeled transition systems from Definition 10. 

Next, consider the equation fi(reoi(A)) = g[ (A), for some BIP architecture A = ({Ci,... ,C n },P, 7 ). 
Suppose that two distinct coordination components Ci and Cj, 1 < i < j < n, each contains an empty- 
labeled transition, i.e., there exist transistions (r/,.0.r/') £ —»•; and (r/ 7 .0. r/' ) £ —tj. When we translate A 
to a port automaton using reoi, the second rule in Definition 8 yields a single transition in fj(reoi(A)) 
from a global state where component Ci is in state q t and Cj is in state qj, to a global state where Ci is 



K. Dokter, S.-S. T. Q. Jongmans, F. Arbab & S. Bliudze 


13 


in state q\ and Cj is in state q'-. However, BIP semantics does not allow independent progress of state¬ 
changing empty-labeled transitions, which means that this single transition exists only when q\ = q t and 
q'j = qj. Indeed, the first rule of Definition 3 allows either C, or Cj to change state, and the second 
rule implies q\ = cp and q'- = qj for N = 0. Because of this, we need to exclude BIP architectures 
where two coordinating components can make a state-changing empty-labeled transition. Moreover, as 
we consider composition of BIP architectures in Section 3.5, we exclude BIP architectures containing a 
single coordinating component that can make a state-changing empty-labeled transition, and restrict Arch 
to Arch 7 = {A6 Arch | VC,- G 2? : q, —® q\ =$■ q] = r/,}. Finally, consider the equation gj ( bip, f.r/)) = 
for some port automaton sF . Note that the interaction model of bip| f.c/j contains the empty 
set. Hence, the second rule in Definition 3 yields empty-labeled self-transitions in g^bipj Since 

fi acts like the identity, we conclude that ,c/ should have empty-labeled self-transitions, i.e., q' = q 
implies (q,Q),q') G —On the other hand, suppose that (q.tt.q') G —K Then the coordinating component 
of bipjf^) should not contain a state-changing empty-labeled transition, hence q' = q. Therefore, we 
restrict PA to PA 7 = G PA | q A- q' q' = q}. 

Theorem 1. For all sF G PA 7 and A G Arch 7 we have gj (bipj (&/)) = f i (&f) and f i (reoi (A)) = g! (A). 

Proof. Using Definition 3, Definition 8, A G Arch 7 , sf G PA 7 , and the fact that (qpM.qp) f —?p, it 
follows that (1) ~ given by (q, qp) ~ q for all q G Q is a bisimulation between g L (bip 1 (^)) and f i (&/), 
where Q is the state space of sf, and (2) « given by (q ,qj) m (q ,qp) for all q = {qfiej G 0/g/ Qi’ a 
bisimulation, where Qj, i G /, arc the state spaces of the coordinating components of A. See [14] for a 
detailed proof. □ 

Corollary 1 . bip j and reoi preserve all properties closed under bisimulation, i.e., for all P C LTS, 
sF G PA 7 and A G Arch 7 we have f i (&/) G P AA gj (bipj (&/)) G P and g L (A) G P 4G f i (reoj (A)) G P. 

Example 7. Consider the following safety property (p satisfied by the Reo connector in Figure 2(c): 
“if b\ fires, then bj fires only after f\ fires”. Clearly, the automaton .?/ 7 , obtained from Figure 4(c) by 
adding empty self-transitions, satisfies this property as well. Using Corollary 1, we conclude that the 
BIP architecture bip, (sf) = bip x (.c/ 7 ) satisfies (p. More generally. Corollary 1 allows model checking of 
BIP architectures with Reo model checkers. A 

3.5 Compatibility with composition 

BIP architectures and port automata have their own notions of composition. This raises the question of 
whether our translations preserve composition structures. We show that, under specific conditions, our 
translations preserve composition modulo semantic equivalence. Recall the port automaton representa¬ 
tion of the interaction model (Section 3.2). 

Lemma 1 . Let A,- = (A). P,. y,) G Arch, i = 1,2, with P/,\ n/V 2 = 0 and 0 G yi n yo. Then, we have that 
srfy l2 ~ sfy j ix sfy,, where Y12 be the interaction model ofA \ 0A2. 

Proof. Follows easily from Definition 8 and Definition 4. See [14] for a detailed proof. □ 

Suppose that reoj(Ai ©At) ~ reoi(Ai) ix reoi(A 2 ), for any two BIP architectures A],A 2 G Arch 7 . 
Definition 8 implies IV reol(Al ® A2) = N^A^eoMi) = ^reofiA,) UlV reol (A 2 )- In other words ' the name set 
of port automaton reoi(Ai © A 2 ) is the union of the name set of the port automata reoi(A,-), i = 1,2. 
Hence, A re0l ( Ai ) C A reoi ( Al ® A2 ), for i = 1,2. This means that the dangling ports of reoi(Ai ©A 2 ) contain 
all dangling ports of reoi(A,-). Therefore, we need to assume that P<z\ Hi P2 = Py; 2 Hi P\ =0. 
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Note that this is only a mild assumption. Indeed, if p G n Ais a dangling port of Pj. connected 
directly to a component in A 1 . Then, we first add a (dangling) port x to A 1 and synchronize p with p' 
by considering the BIP interaction model yj = [N U {x } | p G N G /i} U {/V ^ /V G y }. Finally, we 

rename p to jc in A 2 . The resulting architectures satisfy the assumption. 

Theorem 2. reoi(Ai 0 A 2 ) ~ reoi(Ai) x reoiiAfjfor all A; = Ji) £ Arch', withP^ (IP 2 = P<g 2 fl 

P\ = ID and 0 G yi H Y2■ 

Proof Let = {Ci,..., C n ,..., C m L with C, <£ A) iff i < n. By definition, we have reoi(Ai 0 

Af) = 3^ |J% (C, x ■ ■ ■ C n x C, ;+ i x •••C m x .cA, p ). Next, we use the bisimulation of port automata 
(i.e., constraint automata with data contraint T) as defined in [8]. Composition (x) of port automata is 
commutative and associative up to bisimulation [8]. Using Lemma 1, it follows that reoi(Aj ©A 2 ) = 
3iVj3/V 2 (Ci x • • -C n x .fA,, x C n+ 1 x ■ ■ -Cm x .c/y,). Indeed, since fi is like the identity, it follows that 
semantic equivalence ~ coincides with bisimulation ~ of port automata as defined in [8]. Now, we use 
our assumption that P^ f] Pi = P-/, 2 H P\ =0, and the fact that C\,,.. ,C n , and .cA,, do not use ports from 
Pg 2 . Then, reoi(Ai0A2) = 3/V, (C\ x •••C„ x srfyf) x 3/V 2 (C„+i x ■■■C m x s^yff). We conclude that 
reoi(Ai 0 A 2 ) = reoi(Ai) x reoi(A 2 ). Since, fi is like the identity, it is not hard to see that fi takes 
hi similar port automata to bisimilar labeled transition systems. Therefore, reoi is a homomorphism up 
to semantic equivalence, i.e., reoi(Ai 0 A 2 ) ~ reoi(Ai) x reoi(A 2 ). □ 

Theorem 3. bip, (.jzAj x stff) ~ bipj (gf) 0 bipi(^)/or all G PA 7 . 

Proof. Note that, since f 1 is like the identity, semantic equivalence ~ coincides with bisimulation ~ of 
port automata [ 8 ]. As ~ is a congruence with respect to the composition x of port automata, we conclude 
that ~ is a congruence too (i.e., fi(^/) = fi (,aA), for i = 1 , 2 , implies f 1 (,csAj x srff) = f 1 x srff)). 

Let G PA 7 , i = 1,2, be two port automata. From Theorem 2, we conclude that fi(reoi(Ai 0 
A 2 )) = fi(reoi(Ai) x reoi(A 2 )), for any Ai,A 2 G Arch 7 . Substitute A,- = bipj(^), for / = 1,2. Then, 
f^reo^bip^M) © bip^M))) = fi(reoi(bip,(M)) * reo^bip^^))). Thus, f^reo^bip^^))) = 
gj(bip = fi (#%), for i = 1,2, by Theorem 1. Hence, using that ~ is a congruence, we ob¬ 
tain g, (bipi (.iA|) 0 bip, (. 6 A 2 )) = f 1 (,cA| x sff). Therefore, gj (bipj (gf\) 0 bip, (^ 2 )) = g^bip^M x 
siif). □ 

Example 8. For any two ports x and y, let £^{ x ,y} be the port automaton of a synchronous channel (cf.. Ta¬ 
ble 1), and let Ci Xjy y be its corresponding BIP component. Suppose we need to translate 1x1 ^{b,c} 

to a BIP architecture. Then we first compute bip : (--cA{ ai) }) = ({Cr a / ^)}, {a,a',b,b'}, Y{ a m), with Y{a,b} = 
{0, {a, a'}, {b,b'}, {a,a’,b,b'}}. Next, we compute bipj(^A{ 6c |) = ({Cr fc // c „j}, {b,b",c,c"}, Y{b,c})’ with 
Y{b,c} = {0•{h■//'}, { c , c"},{b.b",c.c "}}. Note that we need to use a double prime now, because oth¬ 
erwise b' would be a shared port of Cr a i b n and Cih" c "\- Using Theorem 3, we find that bip, (=raA w x 
^{b,c} = bipi {^{a,b}) © bip, \&^{b,c}) = ({C{a',b'},C{b", c "}},{a,a',b,b',b",c,c"},Y{ a ,b,c})’ where Y{a.b.c} 
is the composition of Y{a,b} and Y{b.c\- 

Example 9. Consider the port automaton .cA', obtained from Figure 4(c) by adding empty self-transitions. 
If we translate sf to BIP, we obtain a BIP architecture If = bip, (,s/'), which has only a single coordi¬ 
nating component. From Example 4 we conclude sf’ = x #/{ x .?A 2 , where is the port automaton 
in Figure 4(a), .cz), i = 1,2, is the port automaton in Figure 4(b), and .e// is obtained from .cf by adding 
empty self-transitions. Now consider B 3 = bip, (x/f) 0 bip 1 {&?{) 0 bipj (.e/f). Using Definition 4, we 
see that B 3 has three coordinating components. Nevertheless, Theorem 3 shows that Bj, is semantically 
equivalent to B. Therefore, Theorem 3 allows to compute translations compositionally. A 
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4 Stateless CA’s and interaction models 

In Section 3 we established a correspondence between port automata and BIP architectures. Here, we 
offer translations between data-aware connector models in BIP and Reo. 

First we determine the semantic model of the connectors. For BIP connectors we use BIP interac¬ 
tion models, i.e., sets of interaction expressions a, with a single top port that is not a bottom port, and 
whose guard and up functions arc independent of local variables (Definition 5). We assume that every 
top port occurs only in one interaction expression per BIP interaction model. We denote the class of BIP 
interaction models by IM. For the semantics of Reo connectors we take a pair consisting of a constraint 
automaton together with a partition of its node set into source nodes jY s , r , mixed nodes AF m i x , and sink 
nodes wV sn k- We call such pairs constraint automata with polarity. Due to the absence of coordinating 
components in the data sensitive model for BIP, we restrict ourselves here to stateless constraint au¬ 
tomata, since BIP interaction expressions are stateless [6,11]. We write CA + for the class of all stateless 
constraint automata with polarity, with jY src = P = { p* j p £ P] and ^ = P, = {/r, | p 6 P) for 
some set of ports P. This assumption is necessary to enable simulation of bidirectional ports in BIP. The 
reason we explicitly distinguish node types in this semantics is to give direction to dataflow, similar to 
BIP connectors. Usually such node type distinctions are implicit, but for preciseness we encode them as 
a partition within the semantics of Reo connectors. 

As in Section 3, we interpret all connectors as labeled transition systems. Then we define translations 
between Reo connectors (CA + ) and BIP connectors (IM), and show that they preserve properties. 

4.1 Interpretation of BIP and Reo 

An important difference between BIP and Reo involves how they handle data. BIP uses bidirectional 
ports, while Reo treats input and output ports separately. Since the common semantics should support 
both approaches, we duplicate every bidirectional port of BIP to obtain two unidirectional ports, compat¬ 
ible with Reo. The sense of every reference to a bidirectional port in a BIP interaction expression maps 
that bidirectional port to its intended corresponding unidirectional port. 

Let LTS be the class of ah labeled transition systems over an alphabet (D + 1) 2P , where D is a set 
of data items; 1 = {0} contains void or null , modeling the absence of data; and 2 P is the duplicated 
(unidirectional) port set of a set of (bidirectional) ports P, that is, 2P = {p*,p* p £ P}. If data appears 
at p* (i.e., d(p‘ ) / 0 for 8 £ (D+ I ) 2P ). then we interpret this as input to the connector. If data appears 
at p ,, then we interpret this at output from the connector. 

Consider Figure 3(b). Classes CA + and IM consist of constraint automata with polarity and interac¬ 
tion models. Morphisms bip 2 and reo 2 are translations of those classes and f 2 and g 2 are interpretations in 
a common LTS semantics. We do not intend to redefine the semantics of constraint automata with polar¬ 
ity and of interaction models in this section. Hence, we interpret them using their definitions from [8,11]. 

We begin by defining the interpretation of stateless constraint automata with polarity. Given a state¬ 
less constraint automaton with polarity ,s/, we first determine the smallest set of bidirectional ports P 
such that JY^ ed U P and C P*, where and ^Y s l ‘ s k ed are all source and sink nodes that 

occur on a transition of .c?/. Then, we take 2 P as the port names of f 2 (,6/). Finally, we obtain the 
transitions of f 2 (^) by replacing every transition labeled with N,g in s// with a set of transitions la¬ 
beled with 8 £ A (N,g), where A (N,g) contains all data assignments 8 : 2P — > Pd + 1 that satisfy the 
data constraint N, g. We formalize this as follows. Let sY = ({q }, ^Y S rc , -Am - lx . JY sn k be a stateless 
constraint automaton with polarity over a data domain C F. Define = U{^Cl JY src \ q -A- q], and 
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<y Knk gd = U{-^n ^Knk I d d}- Let P be the smallest set, with ■-yl / s l ^ ed C P* and -XK."^ C P*. Define 

f 2 (^) = ({<?}, (^+ 1) 2jP , {(<?, 5,^) | q — Uq,8 G A(lV,g)}), (5) 

where A(N,g ) = {5 : 2P —>• ^ + 1 | 8(2P\N) = {0},5 |= g}. Note that ports in xF src \^V s ^ ed an d 
jP sn k \ ■^nk ' d are important only for composition, which we do not consider in this paper. 

Next, we interpret interaction models F by a single-state labeled transition system with labels de¬ 
scribing all possible dataflows allowed by the guard, and up and down functions of some interaction 
expression in T. Before we provide a formal definition, we first introduce some notation. For every BIP 
interaction expression a, we write P a for its bottom ports, g a for its guard, up “ and upf for the restric¬ 
tion of the up function to its top port and its local variables, respectively, and dn Pol for the restriction of 
the down function to its bottom ports. For every BIP interaction model F. we write P\ = Uagr^co an d 
Dp = U P ePr Dp, where D /( is the data type of port p. For every data assignment 5 : 2P\ —y Dp + 1 we 
define 8 up (p ) = 8(p*) and 8,[ n [p) = 8(p,), for all p <G P a . Then, we define 

g 2 (L) = ({<?}, (D r + 1) 2 M(<?, 5, <?) | a G F,5 s A(a) C (D r + l) 2 ^}), (6) 

where A(a) = {5 | 8(2Pr\2P a ) = {0},g a (<5„ /; ) = tt ,8 dn = dn% ot (up“(S up ),up , £(S up ))}. Note that we 
use the value of up®,(8 up ) as a local variable, since we consider only non-hierarchical interaction models. 

In [11], Bliudze et al. encode BIP interaction models in Top/Bottom components, i.e., an automaton 
over interaction expressions together with local variables. Furthermore, they define a semantics for T/B 
components, which indirectly defines an interpretation of interaction models. Equation (6) imitates this 
interpretation without using Top/Bottom components explicitly. 

Now that we defined the interpretation of our objects in LTS, we explore how these translations 
preserve properties that arc expressible in LTS, as we did for their counterparts in Section 3.1. 

4.2 Reo to BIP 

Since BIP interaction models are stateless, we cannot translate an arbitrary constraint automaton (i.e., 
Reo connector) into BIP. Interaction models in BIP preclude keeping track of the state of a Reo connector. 
Hence, the translation of the interaction model of a BIP architecture into a port automaton in Section 3.2 
inspires us for our translation bip 2 . 

Let sY be a stateless constraint automaton over a data domain Q>. Since we care only about external 
behaviour, we first hide all mixed nodes. Then, we transform every transition in srf with label N,g into a 
simple BIP connector with N as its bottom ports, together with a guard, an up and a down function that 
mimic the data constraint g. We define the corresponding set bip 2 (.f/) of simple BIP connectors by the 
set of all transformed transitions from -o/. 

We first define the transformation of transitions into interaction expressions. Lor every label N, g in 
automaton 8/, we define the simple BIP connector 

= ({vVjVjg} i Pn)-\ gsrc(Xsrc) ■ F sn fc != SOlve(g, X src ) // X sn /i ‘.= F OT fc], 

where Py is the smallest set satisfying /V nC 2Py, g src is any quantifier free formula equivalent to 
3N \ JVsrc : g, the variables Y sn k = {y p \ p G IV fl } arc some fresh local variables, and X src = {x p \ 
p G IVn ■A / ' src } and X sn k = [x p \ p G Ain -A' sn k) model the input and output values assigned to the bottom 
ports, and solve(g,X !rc ) returns a vector Y snk satisfying 3X m ; x : g(X src ,X m ; x . F v „/ f ). All variables have data 
type @ (the data domain of sY), i.e., x p : for all p G jV. Note that the solve function in a(N,g ) is not 



K. Dokter, S.-S. T. Q. Jongmans, F. Arbab & S. Bliudze 


17 


deterministic. However, comparing the solve function to the random function in Figure 4 in [11], we see 
that this generality is justified. Now, we define bip 2 as follows: 

bip 2 (>0 = {a(N,g) I ( q,N,g,q ) € ->}, (7) 


4.3 BIP to Reo 

The correspondence between BIP interaction expressions and automata transitions from Section 4.2, 
provides the main idea for the translation of interaction models into stateless constraint automata. If I is 
a set of simple BIP connectors, we assign to every agfa transition x n labeled with N(tt),g(a), and 
subsequently construct the stateless constraint automaton consisting of all such t a transitions. 

Let a be a simple BIP interaction expression. Recall our relaxation on the data constraint language 
in Section 2, and our notations regarding a in Section 4.1. Then, define N{cx) C 2 P a = {p*,P* | P G P«} 
where p* G N(a) iff a assignes data to p in the upward data transfer, and p, <E N(cx) iff a assigns data 
to p in the downward data transfer. Furthermore, let D, = (d Pt ) pe p, D* = (d p *) pe p, and define 

g(a) = Apepdp*,dp, G Dp A g a {D*) AD* = dnf m (wp“(D *), upf (D*)), 

Note that g(oc) is independent of the top port w, as we consider only non-hierarchical connectors. 

Let r be a set of simple BIP connectors. Recall that Pp = [J a P a and Dp = UpG/y Then, define 
the constraint automaton reo 2 (r) over Dr by 

reo 2 (r) = | a Gr},^r). (8) 

Example 10. Consider the interaction expression a max from Example 2, with the data domains restricted 
to = {0, ...,2 32 — 1}. We translate the interaction model F = {a max } using (8), i.e., we compute 
stf = reo 2 (r). Trivially, srf is stateless. Its set of input ports equals (Pr)* = {a*,b* }, and its set of output 
ports equals (Pr)* = {«*,£*}. It has a unique transitions (q.N.g.q), with synchronization contraint 

N = {a* , b* ,a*, b *} and guard g = : z=m a x(x,y)( d a* = xAd b * = y A d a , = z A d bii = z). A 

4.4 Preservation of properties 

To show the faithfulness of translations bip 2 and reo 2 , we show that interpretations f 2 and g 2 commute 
with the translations bip 2 and reo 2 in Figure 3(b). 

Theorem 4. For all srf G CA 3 " and all F G IM we have g 2 (bip 2 (^/)) = f 2 (^/) and f 2 (reo 2 (T)) = g 2 (r). 

Proof. (Sketch). Let F G IM and sF G CA 1 * 1 . Then, A (a(N,g)) = A(N,g), and A (N(a),g(a)) = A(a), 
for all cx G F. and all transition labels N,g in ,s/. From this and the definitions of f 2 and g 2 , we see that 

g 2 (bip 2 (^/))) = f 2 (.c/), and f 2 (reo 2 (r)) = g 2 (T), respectively. □ 

Corollary 2. The translations bip 2 and reo 2 preserve all properties expressible in LTS, i.e., f 2 f,G/) G 
P g 2 (bip 2 (i 2 /)) G P and g 2 (r) GP<S> f 2 (reo 2 (r)) G P for all P C LTS, srf G CA 1 * 1 and F G IM. 
Example 11. Consider the following safety property <p for the interaction expression a niax from Exam¬ 
ple 2: “the value retrieved from port a equals zero”. Clearly, this safety property does not hold, whenever 
a or b offers a non-zero integer. Note that (p depends solely on the interpretation of the interaction model 
r = {o^ax} in LTS, and hence (p is expressible in LTS. Using Corollary 2 we conclude that <p is false also 
for ^4i ax = reo 2 ({a max }). Thus, we know any executable code generated from the constraint automaton 
does not satisfy (p. More generally. Corollary 2 allows us to use the Reo compiler to generate 
correct code for a BIP interaction model. A 
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5 Conclusions and Future Work 

BIP and Reo find common ground in their stimulation of exogenous system design. This means that 
they force the explicit modeling of coordination constraints. A clear and formal separation between 
coordination (connectors) and computation (components) allows the software architect to analyze the 
interaction of the components using automated tools. The exogenous approach of BIP and Reo contrasts 
with the endogenous approach supported in process algebra and other languages where coordination is 
woven into the code of the components. For example, process algebra does not supply constructs to 
enforce the separation of concerns necessary in exogenous coordination [20]. 

Multiparty synchronization constitutes a fundamental coordination concept in BIP (represented by 
interactions in a BIP interaction model) and Reo (represented by synchronization constraints in constraint 
automata). Our translations show that these representations of multiparty synchronization coincide. 

The BIP framework concretely defines what separates computation (BIP behaviour) and coordination 
(BIP interaction), while Reo merely separates computation (Reo components) and coordination (Reo 
connector) structurally. Indeed, Reo does not force a fixed universal definition for computation and 
coordination in all applications. Without giving a fixed definition of separation criterion, Reo’s structural 
separation of computation from coordination (i.e., component versus connector) simply means that, while 
this separation is always important, the distinction between the two is in the eye of the beholder: in 
different applications, different, or even the same people, may find it convenient to draw the line that 
separates computation and coordination at different places to suit their needs. For example, the stateful 
behavior of a FIFO with capacity of 1 strictly places what this entity does in the behaviour layer of BIP, 
as a (computation) component. In Reo, such stateful components can, of course, be regarded and used 
as computation as well. However, when deemed appropriate, one can use the same component (i.e., a 
FIF01 channel) in the construction of a Reo connector as well, e.g., to express the stateful, turn-taking 
interaction between two components, as in Figure 2. 

Our data-agnostic translations allow compositional translation, because their operators distribute over 
composition modulo semantic equivalence. On the other hand, our data-sensitive translation scheme does 
not support incremental translation. It seems intuitive to translate synchronous Reo channels into BIP 
interaction expressions. However, the directionality inherent in the dataflows of BIP interaction expres¬ 
sions implies that they can compose only hierarchically, whereas the relational specification of dataflow 
constraints in Reo (which manifests itself as data constraints in constraint automata transition labels) al¬ 
lows more expressive composition of dataflows as relational composition of constraints. This difference 
restricts the set of the Reo connectors that this scheme can incrementally translate into BIP, as well as the 
granularity of the sub-connectors that it can translate in one increment: the data constraints on the bound¬ 
ary nodes of every such sub-connector must be locally resolvable into a directional dataflow expression 
at the level of the sub-connector, in isolation. In practice, synchronous cycles in a Reo connector must 
translate as a whole, which scuttles the computational benefit of translating incrementally. 

In contrast with the BIP architecture model, the data-sensitive model for BIP does not include coordi¬ 
nating components within the connector [6,11]. Nevertheless, it seems possible to use the formalization 
in [11] to extend BIP architectures of [6] with data. However, extending the current composition operator 
0 to compose data-sensitive BIP architectures does not seem trivial, and we do not know what properties 
such an extended composition operator can preserve. 

Using the ideas from Section 3, extending our reo 2 translation (Figure 3(b)) to the domain of pos¬ 
tulated data-sensitive BIP architectures seems straight-forward. Moreover, it may be possible to extend 
our translations to mappings that preserve internal ports. Such extensions, together with the results from 
Section 4, effectively promise a property-preserving composition operator for data-sensitive BIP archi- 
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tectures that may also share internal ports. 
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